REMARKS 

The Office Action issued January 9, 2007, has been 
received and its contents have been carefully noted. 

In it, the Examiner has objected to applicant's 
specification as "failing to support the subject matter set 
forth in the claims. The specification, as originally filed 
does not provide support for the invention as now claimed." 

In the Examiner's interpretation, the following 
limitations are not supported by the original specification: 
^^,..pr±or to said transaction reaching Its processing host 
system and prior to said prospective credit or debit 
transaction request reaching Its processing host system 
ultimately responsible for approving or denying the charge^ 
said delivery of the previously set borrowing account In 
response to a request carrying the corresponding 
authorization code. Information from the trigger server, 
said request a separate communication session Independent of 
the financial transaction Itself and prior to said 
prospective credit or debit transaction request reaching Its 
financial Institution's processing host system ultimately 
responsible for approving or denying the charge,, enabling 
said financial Institution' s processing host system to 
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receive said transaction request along with said downloaded 
account and associated account approval information 
necessary for the effective use of the account. In place of 
the authorization code initially presented to said terminal 
as the alternative payment method for said prospective 
credit or debit transaction, said account and associated 
account approval information to be used in said transaction, 
said account and associated account approval information to 
be used in said prospective credit or debit transaction 
between said terminal and host, " 

The Examiner deemed this language as ^^contalnlng 
subject matter which was not described in the specification 
in such a way as to reasonably convey to one skilled in the 
relevant art that the Inventor (s) , at the time the 
application was filed, had possession of the claimed 
Invention. In particular, claims 1-12, 13-24,26-39 are 
rejected under 35 U.S.C. § 112, for the reason set forth in 
the objection to the specification. 

Applicant respectfully disagrees with the Examiner in 
his interpretation that one skilled in the art could not 
reasonably conceive of and implement the limitation now 
added into the claims in view of the original disclosure, as 
filed. To the contrary, applicant considers this limitation 



an intrinsic part of the original design and his 
corresponding application, not only apparent but principally 
explicit and obvious to anyone skilled in the art as the 
following remarks will demonstrate. 

The "newly added limitation", deemed unsupported by the 
Examiner, is nothing but the repositioning of the original 
claims to better distinguish the terminal implementation of 
the trigger system, in place of the initially proposed host 
implementation, which is no longer applicable to this 
system. This limitation added to the claims is intended 
simply to exclude the host implementation of the trigger 
system, while emphasizing the original terminal 
implementation and its characteristics, clearly recited and 
supported by the initial filling and its attached drawings . 

Since its inception, the trigger system was 
conceptualized and subsequently filed with two possible 
implementations, a terminal implementation and host one; 
however, concerns over similarities between it's host 
implementation and prior existing art called re-focusing the 
claims around the terminal model and excluding the original 
host implementation . 

In the terminal implementation of the trigger system, 
the terminal receives a secret code and uses it to retrieve 



the account from the trigger server before submitting the 

charge request to the credit card host system; whereas in 

the host implementation, the terminal sends the secret code 

to the credit card host system, leaving to the host the 

responsibility to connect to the trigger server and retrieve 

the account information it needs for validating the charge 

after receiving the transaction request from the terminal. 

Those two originally presented implementations are 

clearly defined and explained with reference to Figures 3 

and 4 of the original filing: 

^^FIG. 3 is a diagram of the system of the invention 
which provides remote cardies s approval through 
triggers via a terminal connection" (Page 16, Lines 12- 
13) and ^^FIG. 4 is a diagram of the system of the 
invention which provides remote cardless approval 
through triggers via a host connection" (Page 16, Lines 
14-15) , 

The addition of this limitation to the claims, now 
cited by the Examiner as grounds for rejection, was made to 
overcome similarities to other previously presented art, by 
better tailoring those claims away from the initially 
recited ^^dual" implementation of the trigger system, more 
specifically, excluding the host one (Fig 4) . 

Once stripped of its host implementation, the remaining 
terminal implementation" of the trigger system, as 
disclosed in Figure 3 and further described throughout the 



initial filing, not only provides full support for the 
language established in the current claims, but above all 
substantiates the irrefutable fact that applicant had 
complete possession of the claimed invention at the time the 
application was originally filed. 

In his office action, the Examiner states that no 
support exists in the original filing to substantiate that 
the exchange of the account information by the secret code 
occurs ^^...prlor to said transaction reaching Its processing 
host system^^ and ^^prlor to said prospective credit or debit 
transaction request reaching Its processing host system 
ultimately responsible for approving or denying the charge 
and ^^prlor to said prospective credit or debit transaction 
request reaching its financial institution^ s processing host 
system ultimately responsible for approving or denying the 
charge" . 



6 




TRIGGER 
REQUEST 



□ 



1 405 II 403 1 







TRIGGER 
SERVER 

-4001 



TRIGGER 
CONNECTION 
VIA TERMINAL 



□ 



mo(=] 



COLLECTION 
TERMINAL 
ATM 



FINANCES 



40 



TRANSACTION 







pEQUEi 


3T 




401 




402 


403 




' 



NETWORK CONNECTION 1 



REPLY 



41 

45 

SETTLEMENT 



SOURCE 
ACCOUNT 
HOST SYSTEM 



FINANCES 



Fig. 3 



Looking at Figure 3 , it can be seen that the request 
(40) from terminal (A) to the financial institution' s 
processing host system (B) carries the source account 
information 401. We can also identify that said source 
account 401 is shown as being received from the trigger 
server (D) in the reply 4001, as a result of trigger request 
4000. 

That fact alone corroborates that the trigger request 
4000 occurs prior to transaction request 40 reaching the 
SOURCE ACCOUNT HOST SYSTEM (B) , since transaction request 40 
carries with it account 401 received in the reply 4001 from 
trigger server (D) (reply to request 4000) , 
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The only possible way transaction 40 could carry 
account 401 to host B, is if the download of the account 401 
from trigger server (D) occurred prior to transaction 
request 40 being sent to accountholder' s host system B. 

The initial filing additionally recites that only "If 
reply 4001 is approved , source account information is made 
available to terminal A, so that terminal A can attempt a 

transaction request 40 to the host system at the 

institution B" (Page 17, Lines 16-19). This also confirms 
the fact that the terminal could not have had the necessary 
information for initiating charge request 40, unless it had 
downloaded account 401 prior to the transaction request 40 
being submitted to account's host system B for approval. 

This fact can be also substantiated on page 17, lines 
19-20, where the applicant states that "the transaction 
request 40 is comprised of: source account information 401 
received from a trigger server D" . 

Independent claim 1 (c) in the original filing also 
recites that the system comprises "a requesting terminal at 
which the first person to enter the secret code is provided 
the source account approval information for a transaction up 
to the cap limit to the institution in which the previously 
provided source account is maintained'^ (page 38, lines 11- 
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14) , which also means that the source account is given to 
the ^^requesting terminal" for a transaction "to the 
institution" in which the account is maintained once one 
supplies the corresponding secret code to the teirminal . 

The specification also explains that a terminal A can 
only attempt a transaction request to the account host once 
"reply 4001 is approved and source account information is 
made available to terminal A, so that terminal A can attempt 

a transaction request 40 to the host system at the 

institution B at which the source account 401 is maintained" 
(page 17, lines 16-19) . 

All the aforementioned references show unequivocally 
that the request to the trigger server (4000) followed by 
its corresponding reply (4001) occurs prior to the 
transaction (40) reaching its processing host system (B) . 

It is equally apparent that the transaction request 
(40) can be considered a ^^prospective credit or debit 
transaction reqaest^^ since the transaction can only be 
attempted once "reply 4001 is approved" and "source account 
information is made available to terminal A" (page 17, lines 
16-17) . Only once in possession of account information 401, 
"terminal A can attempt a transaction request 40 to the 
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host system at the institution B at which the source account 
401 is maintained" (page 17, lines 17-19) . 

By the time the account information (401) is received 
back from the trigger server (D) on reply 4001, the 
transaction request 40 not yet submitted by terminal A to 
its host system B is only "an event still likely to occur": 
not a certain, but potential and/or probable, therefore 
prospective , event . 

Therefore, not only does the description of Figure 3 
show that the exchange of the account information (401) 
occurs prior to the transaction request 40 being submitted 
to the host system B (in the drawings described as SOURCE 
ACCOUNT HOST SYSTEM) , it clearly states that "A reply 41 to 
the request 40 from source account institution B to 
collection terminal A will approve or deny the transfer of 
the funds " (page 18, lines 1-2), validating that the request 
is indeed not only ^^reaching Its processing host system^\ 
but also that the host system is "ultimately responsible for 
approving or denying the charge ^\ 

Finally, on page 14, lines 14-17, the specification 
states: ^^When a trigger request is issued by a terminal 
connected to the trigger server (Fig. 3) , the terminal A 
first obtains the source account approval information from 
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the trigger server D, before connecting to its host B to 
seek approval for the transaction", clearly substantiating 
that transaction request 40 between terminal A and account 
institution B occurs ^^prior to said prospective credit or 
debit transaction request reaching its financial 
institution's processing host system ultimately responsible 
for approving or denying the charge" . 

The Examiner also claims that no support exists for the 
claim limitation, ^\..sa±d delivery of the previously set 
borrowing account In response to a request carrying the 
corresponding authorization code. 

Again, Figure 3 explains that the delivery of the 
account occurs as a result of a request carrying the secret 
code: ^^The collection terminal requests a funds transfer... 
...providing instead of an account approval information, a 

secret code 405 to acquire the source account information 

401 from trigger server D " (page 17, lines 13-16) . 

Figure 3 also clearly shows that the trigger server is 
the one ^^dellverlng the borrowing account (401) , and that 
the delivery of the account (401) occurs as a response to 
trigger request 4000 carrying the corresponding secret code 
405. 
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The fact that each secret code (405) is mapped to, and 
corresponds to an individual account/approval is a basic 
functional premise of the trigger system and support for it 
can be found throughout the specification, as in: 

"They are debit and credit transaction approvals stored 
under a logical secret code for remote future use" (page 21, 
lines 8-9) ; and 

"delivery of the stored approval information to the 
first teirminal or host presenter of the matching secret 
code" (page 21, lines 11-12). 

Figure 3, clearly demonstrates also that the delivery 
of the account (401) on reply (4001) occurs off of a direct 
request 4000 carrying the secret code 405 . 
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",..a trigger server which stores account information, 
authorization and secret code; and a requesting terminal at 
which the first to provide the secret code is given the 
source account approval information ^^ (page 13, lines 11-14) . 

Other references corroborate that the transaction has 
been previously set, to be later used via its secret code: 

. . . delivery of the previously stored source account 
information to the first presenter of its matching secret 
code" (page 35, lines 17-18); and 

... an input terminal in which a source accountholder 

provides data indicating a source account all of which are 

transmitted to a trigger server which stores source account 

information and a requesting terminal at which the first 

to provide the secret code is given the source account for 

a transaction to the institution in which the previously 

provided source account is maintained" (page 12, lines 1- 
10) . 

The original application, as filed, refers to the 
account in a generic manner, calling it ^^source account 
approval information" or ^^approval information" . Such 
language is meant to remind us that not only is the account 
number itself stored by the trigger server and passed back 
to the terminal, but also any other necessary "approval 
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information" (PIN number for a debit card or maybe a zip 
code for a credit card) necessary for the effective use of 
the account. 

The trigger system is configured to store and simulate 
the delivery of the account plus PIN number (or other 
required approval" data) as if they had been supplied 
directly by the accountholder himself as evidenced in : 

. .a system that supplies account approval information 

for credit and debit transactions to terminals committing 

itself to a single successful delivery of the previously 
stored source account information to the first presenter of 

i'ts matching secret code so it can be used as if the 

requestor for the funds were the cardholder, with his 

card, providing his pin number, at the time and terminal 
where the request originates," (page 35, lines 15-21). 

Although the particular adjectives, "borrowing" for the 
account and "authorization" for the secret code , have not 
been explicitly used in the specification, it is not a 
stretch to argue that the secret code is used to "authorize" 
the use of the account on a subsequent charge request, 
therefore properly called an "authorization code" . 

"The system binds charge approvals to secret codes that 
can be easily transferred to others and used across multiple 
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terminals. Triggered authorizations allow for fixed amount 
account authorizations to be transferred to others as the 
right for a predefined cap cunount charge attempt against a 
particular account under predetermined conditions" (page 32, 
lines 6-10) . 

With regard to the term ^^borrowing" when referring to 
the account, such term serves to more clearly express that 
the account belongs most likely to someone other than the 
individual downloading and using it (who is therefore indeed 
^^borrowing" it from the accountholder for a transaction in 
his/her behalf) . 

The adjective was introduced mainly to facilitate the 
understanding of the art and to more clearly exemplify the 
concept of someone utilizing someone else's account, which 
is well documented and disclosed throughout the original 
specification . 

In the original text, there are numerous references to 
the fact that the person attempting the charge and utilizing 
the account 401 in transaction request 40 is most likely not 
the original owner of the account, which substantiates the 
concept of "borrowing" the account from its original owner. 

Such references can be found in phrases such as : 
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^^allows an accountholder to authorize charges and 
withdrawals to be presented later by someone other than the 
accountholder and who may have no relationship to the 
institution where the accountholder ' s account is 
maintained." (page 2, lines 15-18). 

"It is a further object of the invention to provide a 
system that allows accountholders to authorize withdrawals 
and charges to be presented by someone other than the 
accountholder and who may have no relationship to the 
institution where the account is maintained'' (page 10, lines 
1-4) . 

"Enabling account withdrawals and charges by someone 
other than an accountholder " (page 12, line 5). 

"Providing access to charges and withdrawals by someone 
other than an accountholder and who may be unrelated to the 
institution where the account is maintained" (page 33, line 
21, to page 34, line 2) . 

The use of the adjective "borrowing" to describe the 
functional use of the account was introduced simply to 
clarify the process and to facilitate the understanding of 
the patent itself, by expressing the fact that the person 
downloading the account and using it in his/her behalf is 
most likely not the owner of the account , thereby 
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^^borrowing" the account from the original owner for a 
withdrawal or charge attempt (40) under the owner's consent 
(consent expressed by the knowledge of the secret code 
itself, initially known only to the accountholder and then 
passed to the ^^borrower" of the account) . 

The language stating that the "delivery of the 
previously set borrowing account is "in response to a 
request carrying the corresponding authorization code^^ since 
this feature is in itself, the basis of the entire trigger 
system, where an individual uses a pre-established secret 
code to download and use someone else' s account under pre- 
defined conditions. 

This basic principal is again thoroughly displayed and 
recited not only in Figure 3, but also in several passages 

like "an individual at the institution A. requests a funds 

transfer providing instead of an account approval 

information, a secret code 405 needed. to acquire the 

source account information 401 from trigger server D. If 
reply 4001 is approved, source account information is made 
available to teinninal A, so that terminal A can attempt a 

transaction request 40 to the host system at the 

institution B at which the source account 401 is maintained" 
(page 17, lines 12-19) . 
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Page 21, lines 15-17 also mention that the trigger 
server is "responsible for providing the source account 
approval information for a transaction up to its cap value 
to whichever beneficiary host or terminal presents the 
matching secret code" (please note that instead of host or 
terminal , only the terminal implementation will be supported 
due to the recent added limitation) . 

This concept is again substantiated in several 
different paragraphs of the original application, such as: 

"It allows for source account approvals used in credit 
and debit transaction requests to be received and safely 
stored (encrypted) by a third party system (the trigger 
server D) so that account approval can be used later by 
other terminals through its secret code " (page 31, lines 13- 
16) . 

". . .a requesting terminal at which the first to provide 
the secret code is given the source account approval 
information for a transaction up to the cap limit to the 
institution in which the previously provided source account 
is maintained" (page 11, lines 7-10) . 

"The trigger's host system will acknowledge the 

right to a single successful delivery of the stored approval 
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information to the first terminal presenter of the 

matching secret code" (page 20, lines 10-12) . 

As ground for rejection, the Examiner also claims no 
support for: 

^\.. Information from the trigger server^ said request a 
separate cowmmication session independent of the financial 
transaction itself. . • 

Going back to the terminal implementation of the 
trigger system (Figure 3) , it may be seen that there are two 
different and independent sets of requests (4000 and 40) : 
one to the trigger server (4000) to acquire the account 
(401) and another (40) to the account host (B) to attempt a 
charge or withdrawal . 

In the first one, terminal A posts a request 4000 to 
trigger server D containing the secret code 405 in an 
attempt to acquire the account information 401, Request 4000 
can be considered a "download account" request between the 
terminal A and the trigger server D. 

If the trigger request 4000 is approved in reply 4001, 
and the terminal successfully downloads account 401, a 
separate transaction request 40 is then initiated seeking a 
charge or withdrawal against account's host B. 
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The charge request 40 carries the account information 
401 received from the trigger server D and it is, by design, 
independent of the trigger process responsible for the 
downloading of the account itself. 

Teinainal A and host B will ultimately negotiate and 
engage in a transaction ^^privately" , with host B approving 
or denying transaction request 40 directly to terminal A via 
reply 41, 

The independence of the trigger server from the overall 
transaction is intrinsic and inherent to the trigger system 
and is confirmed by a ntimber of statements in the original 
specification , such as : 

^^The system and method of the invention allows 
terminals and hosts equipped with enabling software, to 
collect the source account approval infoinnation from the 
trigger system, outside their private transaction" (page 14, 
lines 19-21) . 

"It is a further object of the invention to provide a 
system where the service provider institution is not 
required to be participant in the actual financial 
transaction between the requesting terminal and source 
account institution" (page 10, lines 13-15) . 
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"A reply 41 to the request 40 from source account 
institution B to collection terminal A will approve or deny 
the transfer of the funds. In case of approval on reply 41, 
settlement for the transfer of funds 45 will occur directly 
from source account institution B to collection terminal 
institution A." (page 18, lines 1-4). 

^^In addition, it is intended to protect the privacy and 
security of the transaction between terminal and host, 
separating the process by which the host or terminal acquire 
the source account approval information for the transaction 
from the process where the terminal-host private financial 
transaction and money transfer occurs." (page 23, lines 12- 
16) . 

^^Host and terminal will then in a separate transaction , 
validate or not validate such credit or debit transaction 
using the source account inf oxnnation provided by the trigger 
server." (page 27, lines 15-17). 

^'In the trigger system, the trigger server D does not 
participate in the money transfer transaction itself" (page 
14, lines 11-12) . 

^^It is a disconnected system designed in a way that the 
collection terminal institution A and the source account 
institution B are the ones performing the transaction... 
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...among each other without the participation of the 
institution that provides the source account approval 
information D" (page 16, lines 1-5) . 

The Examiner also concludes that ^\..enabl±ng said 
financial Institution^ s processing host system to receive 
said transaction request along with said downloaded account 
and associated account approval Information necessary for 
the effective use of the account" is not supported by the 
initial filling. 

Figure 3 and its associated description clearly points 
out that the account received by host B in request 40 is 
again given by the trigger server: "The transaction request 
40 is comprised of source account information 401 received 
from a trigger server D" (page 17, lines 19-20). 

Also, given that account information (credit or debit 
card info plus pin/approval) is a requirement for the 
financial institution to process the transaction, one can 
correctly affirm that the trigger server (D) , by supplying 
the account (401) , enabled the transaction to occur, in view 
of the fact that no transaction could ever be accomplished 
without it. 

The transaction request 40 can ultimately only be 
processed by account host (B) because the account (401) is 
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supplied by the trigger server (D) . Therefore, the trigger 
server is correctly stated to be the enabler of the 
transaction (40) . It is also correct to state that the 
account information (401) is ^^necessary for the effective 
use of the account since no transaction is possible unless 
the terminal collects the account and necessary approval 
information 401 from the trigger server (D) . 

The Examiner also finds lack of support for indicating 
that the trigger server is ultimately the one who enables 
the credit card host system to receive the account 
information (credit card data plus approval /pin) "in place 
of the authorization code Initially presented to said 
tejnnlnal as the alternative payment method for said 
prospective credit or debit transaction^^ 

Support for this may be found throughout the original 
specification, for example: 

^',..an individual at the institution A that maintains 
the collection terminal requests a funds transfer for an 
amount 403 providing instead of an account approval 
information, a secret code 405 needed by the trigger request 
4000 to acquire the source account information 401 from 
trigger server D" (page 17, lines 12-16) . 
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The specification as well as the drawings unequivocally 
recite and display that the terminal receives a secret code 
instead of the account information and that the secret code 
is used by the terminal to request (4000) the account (401) 
from the trigger server (D) . Once the account information 
(401) is downloaded (4001) , it is used in prospective 
transaction 40 . 

Figure 3 also shows that the transaction request 40 
between terminal A and host B does not carry the secret code 
405, but instead, carries the account information 401 
downloaded from the trigger server D and required by the 
host (B) to perform a transaction 40 . 

The fact that the trigger system allows a transaction 
to be initiated by a terminal receiving an authorization 
code (secret code) instead of an account, and utilize the 
secret code to download the account information to be sent 
in transaction request 40, clearly supports the statement 
that the secret code is an alternative payment method for 
the transaction since from a customer's perspective, the 
"authorization code" is the instrument used as the money 
source for the transaction. 

Similarly, in applicant's view, there should be little 
dispute that the account 401, once received from trigger 
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server D in reply 4001, is used as the charge account 
(transaction request 40) "in place of the authorization code 
Initially presented to said terminal as the alternative 
payment method for said prospective credit or debit 
transaction " . 

The use of the term, ^^alternative payment method^\ 
relates to the fact that the trigger system is not only a 
payment system as described by quotes such as : 

intended to provide financial institutions and 
their customers, cardless triggered money transfer and 
payment capabilities " (page 29, lines 4-5) . 

"The system provides money transfer and payment 
capabilities using existing accounts, to access terminals 
and networks" (page 30, lines 16-17) . 

"They are pre-approved-charge-requests , which provide 

cash and credit accountholders cardless withdrawals, money 

transfers and payment capabilities based on secret codes" 
(Page 20, Lines 5-8) . 

The use of the word "alternative" also refers to the 
fact that this new "trigger payment method" does not yet 
exist and therefore is considered "alternative" to the 
existing payment methods currently available to customers. 
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The Examiner has apparently overlooked the support, in 
applicant's original disclosure, for the affirmation that 
"the accovmt and associated account approval Information to 
be used in the transaction^^ and "the account and associated 
account approval information to be used in the prospective 
credit or debit transaction between the terminal and host^\ 

References that the account and approval information 
downloaded by terminal (A) from the trigger system (D) are 
intended to be used in transaction 40 between the terminal 
(A) and the host (B) are not only evident in Figure 3, but 
also as well in numerous other paragraphs, for example: 

"Terminals and hosts on the trigger system perform 
transactions between each other utilizing approvals 
collected from the trigger system , instead of from the 
accountholder" (page 35, lines 1-3) , 

"When a trigger request is issued by a terminal 
connected to the trigger server (Fig. 3) , the terminal A 
first obtains the source account approval information from 
the trigger server D, before connecting to its host B to 
seek approval for the transaction." (page 13, lines 14-17). 

"If reply 4001 is approved, source account information 
is made available to terminal A, so that terminal A can 
attempt a transaction request 40 to the host system at the 
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institution B at which the source account 401 is maintained. 

The transaction request 40 is comprised of : source account 
information 401 received from a trigger server D" (page 17, 
lines 16-20) . 

"The trigger system provides source account and 
approval information for transactions between a terminal and 
an account institution through electronic transmission 
methods" (page 31, line 19, to page 32, line 1) . 

"The purpose of the invention is to store and forward 
approvals for transactions between terminals and hosts" 
(page 33, lines 19-21) . 

In summary, the Examiner's rejection is based on the 
premise that the original filing had no support for the 
following main concepts recited in the newly modified 
claims : 

1) Secret code is given to the terminal as alternative 
payment method for the transaction. 

'^authorization code Initially presentBd to said 
terminal as the alternative payment method for said 
prospective credit or debit transaction. 

2) Secret code is used by terminal to acquire the 
corresponding account from the trigger server. 



Pi 

^^sald delivery of the previously set borrowing 
Bccovmt In response to a request carrying the 
corresponding authorization code, 



3) The account downloaded from the trigger server is 
used in a transaction between the terminal and the host. 

^^sald account and associated account approval 
Information to be used In said transaction, said 
account and associated account approval Information to 
be used In said prospective credit or debit transaction 
between said terminal and host. 



4) Host receives a transaction request from the 
terminal with account information instead of with secret 
code . 

^^In place of the authorization code Initially 
presented to said termlnal^^ . 



5) Download of account information occurs before the 
charge request is sent to the host. 

""""prior to said transaction reaching Its processing 
host system and prior to said prospective credit or 
debit transaction request reaching Its processing host 
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system and prior to said prospective credit or debit 
transaction request reaching its financial 
institution^ s processing host system^\ 

6) Delivery of the account between the trigger server 
and the terminal is independent of the charge transaction 
between the terminal and the account host. 

^^Inforxaation from the trigger server^ said request 
a separate communication session independent of the 
financial transaction itself ^\ 

7) Host is responsible for approving or denying the 
charge , 

^^processing host system ultimately responsible for 
approving or denying the charge and financial 
institution^ s processing host system ultimately 
responsible for approving or denying the charge^\ 

8) The Trigger server is the one enabling the host to 
receive the account in the transaction request instead of 
the secret code initially presented to the terminal . 

^^enabling said financial institution^ s processing 
host system to receive said transaction request along 



with said downloaded accovmt and associated account 
approval Information necessary for the effective use of 
the account . 

In reply, applicant submits that the original 
disclosure of this application, which includes its described 
terminal implementation, drawings and claims, as well as all 
above mentioned references, unequivocally demonstrates that: 

1) A secret code is given to the terminal as 
alternative payment method for the transaction, 2) a secret 
code is used by terminal to acquire the corresponding 
account from the trigger server, 3) the account downloaded 
from the trigger server is used in a transaction between the 
terminal and the host, 4) the host receives transaction 
request from terminal with account information instead of 
with secret code, (5) download of account information occurs 
before the charge request is sent to the host, (6) delivery 
of the account between the trigger server and the terminal 
is independent of the charge transaction between the 
terminal and the account host, (7) the host is responsible 
for approving or denying the charge, and (8) the trigger 
server is the one enabling the host to receive the account 
in the transaction request instead of the secret code 
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initially presented to the terminal . See Fig 3 ; page 2 , 
lines 15-18; page 10, lines 1-4, 13-15; page 11, lines 7-10; 
page 12, lines 1-10; page 13, lines 11-17; page 14, lines 
11-12, 14-17, 19-21; page 16, lines 1-5, 12-15; page 17, 
lines 12-20; page 18, Lines 1-4; page 20, lines 5-8, 10-12; 
page 21, lines 8-9, 11-12, 15-17; page 23, lines 12-16; page 
27, lines 15-17; page 29, lines 4-5; page 30, lines 16-17; 
page 31, lines 13-16, 19 to page 32, line 1; page 32, lines 
6-10; page 33, line 19 to page 34, line 2; page 35, lines 1- 
3, 15-21, 17-18 and page 38, lines 11-14. 

In conclusion, therefore, it is respectfully submitted 
that the limitations now included in the claims, not only 
"reasonably convey to one skilled in the relevant art that 
the inventor, at the time the application was filed, had 
possession of the claimed invention", but unquestionably 
prove that the limitations have always been an intrinsic 
part of the original art, fully recited and supported as the 
terminal implementation of the trigger system (Fig 3) , 

The inclusion of these limitations in the claims is 
nothing more than an attempt to distinguish the invention 
from other cited prior art, by excluding one of the two 
initially proposed implementations of the trigger system 
(the host-to-host implementation) with language more 
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pertinent to the terminal only implementation of the system 



and method. 

The remaining terminal implementation of the trigger 
system as well as the modified claim language aimed to 
properly disclose its boundaries is thus believed to be 
fully supported by the initial drawings and the 
corresponding description in the specification. 

Consequently, for all the reasons given above, this 
application is believed to be in condition for immediate 
allowance. A formal Notice of Allowance is accordingly 
respectfully solicited. 
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